-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-enable waiting for processing by default, using the new API semantics. #1007
Conversation
c40126e
to
9885f86
Compare
Would you mind if we hold this until next week when we've fixed the SHA of |
6224a8a
to
e7869d5
Compare
A thought I had just after approving: There was previously an issue with the API end-point that has now been fixed, right? But does that mean this could cause problems for users on old versions of GHES who pull in a new version of the Action? Should we gate this to only work on dot com or on new versions of GHES? |
I appreciate the switch to a warning means we won't fail, but it would still be nice to avoid warnings in the log. |
So you will still get a warning on old GHES versions, that is true. When I was implementing this it seemed somewhat reasonable to me, because it is indeed true that we cannot tell you if your analysis processing will fail. I can add a check for the GHES version if you think this is not the best behavior though. |
Hmm, I guess it's fine to have a warning in the logs in the fairly rare case of a pull request from a fork in a GHES instance. Or at least, it's probably not worth the extra complexity of having version checks in the code. Let's leave this as-is. |
This re-enables waiting for processing by default, after some changes to the API which will allow it to work on pull requests from forks.
It also makes it more tolerant of errors returned by the API, since waiting for processing is not essential.
Merge / deployment checklist